Background : There are various complex cells (single/multi-bit) that
are not automatically mapped on to in synthesis, even if they are
modeled in the target library. These cells are generally usefull in the
generation of datapath designs. They also have the advantage that the cells
are handpacked and optimized. This gives rise to the added benefit that
there will be less cells to place and route. The timing of these blocks
will also be more predictable because bigger blocks have been characterized. 


ABSTRACT: This example will highlight and walk designers through a testcase 
where complex cells can be automatically brought into the end users design 
without any manual intervention of the designer.  DesignWare(DW) is the 
mechanism that enables this "auto" selection and insertion of complex cells
into the end design.

This example design takes DesignWare Developers through the process
of creating a VHDL "wrapper" file that will generate an adder design that
will instantiate the complex cells (XX4FA : 4 bit full adder, XXFA : 1 bit
full adder) that are available in the ASIC Vendors Library. The link
between the DW part and the "synthetic operator" are also shown. Thus 
end users will be able to get technology specific hard-macros in their
design from an technology independent HDL representation (in this case
from a "+" ).


DESCRIPTION :
There are two main steps involved in making your own DW part, creation
and verification. There are a couple of assumptions made in the 
creation of this design :
1)The complex cells that need to be incorporated in the design are 
characterized in the target library. Please see xx.lib for an example
of the characterization (please refer to Library Compiler on Syntax,
methodology and limitations). 
2)Simulation models of the complex cells are also needed for simulation 
verification purposes. 
3)The reader of this document is familiar with (V)HDL-Compiler, DesignCompiler,
VHDL, DesignWare Developer and Library Compiler.


The first step to be taken when creating your own DW part is the 
characterization of the Synopsys DW equivalent components performance.
The DW developer should also estimate the performance of his/her own designs
that will incorporate the complex cells and see if they are better than the
Synopsys supplied parts. Once this has been verified the DW developer
will go on to write a VHDL file will that will generate a structural netlist
that incorporates these complex cells correctly for any bit-width. This
is similar to writing a netlist generator in "C", the only difference
being that the netlist generator is written in VHDL.

Another step that can be used to guide the developers of these
parts is the overlap with the Synopsys DW parts. These parts are
some of the most commonly used designs and most designers would
prefer to have them available. Developers should also poll their
prospective customer base and see the demand for special components
that they would like to have access to.

An important factor to take into account after the selection
process, is the naming of the designs that have been shortlisted.
DW Developers can use the same entity/module names as the synopsys
supplied DW parts if they are satisified with the behavior
as well as the ports of the design. The advantage with having
the same name as a synopsys DW part is that users can be 
assured of technology independence because the synopsys
DW part will map to any technology. They do not need to 
manually modify the design to migrate between technologies.

The DW developer will also write a synthetic library file that
contains the interface information that VHDL-Compiler/Design-Compiler(DC)
needs to perform High Level Optimizations (HLO) and autolink in the part. 

The sequence of events necessary to create the DesignWare complex cell
generator is given below.

FLOW	: 
	 1) Create entity declaration with port names and generics.
		For this design the entity name is XX_ADD. It is generally
		a good idea to name the file the same as the entity name.
         2) Create the architecture that generates the netlist that instantiates
	    the hard macros (leaf cells).
		In this example the architecture is called RPL.
		The architecture consists of an algorithm whose function
		is to interconnect 4 bit and 1 bit cells together based
		on the input bit-width.
		After implementing the VHDL description for generating the
		netlist, developers should create an embedded DC script.
		Embedded scripts are essential for proper implementation 
		selection. These modeling directives are used to characterize
		the expected environment of the design. The timing models
		created with these directives will be used during implementation
		selection.
                Place dont_touch attributes on the hardmaccro cells
		    [This will prevent the replacement of the hardamcro with
		     gates if there is a function statement available in the
		     library compiler description]
		     Note : placing of dont_touch will prevent constant
		     propogation.
	 2) Create timing models for the leaf cells if not available already.
	    The most important factor is that timing arcs are available for 
	    design compiler to use while timing through the design.
	    These do not need to have function statements in them.  
         3) Compile the timing models using library compiler 
	 (read_lib/report_lib/write_lib)
	 2) Create simulation models of the leaf cells for simulation 
	 verification of the elaborated designs. 
	 3) Create the sl file.
		Enter the module and implementation names.
		Enter the name of the library where the analyzed files will 
		exist.
		Place the bindings for proper inference of this component 
		from HDL.
                [ The creation of bindings is optional and is necessary for 
		  parts that are to be inferred.] 
	 4) Analyze the xx_add.vhd and xx_add_rpl.vhd into the library asicxx.
	    [While performing simulation verification, designs could be analyzed
	     into the work directory for ease.]
            [ dc_shell> analyze -f < format > <file_name) -lib <logical name>] 
	    
	 5) Simulate the implementation to verify that results are accurate.
		analyze the xx_add_tb.vhd and cfg_tb.vhd into the library asicxx
		(OR work)
		{ The above step is only for simulation purposes }	
                [ use vhdlan if you are using VSS ]
	 5) Elaborate and time the design in design compiler.
            [dc_shell>elaborate <entity_name> -arch <arch_name> 
	    -lib <library_where_it_was_analyzed_into> 
	    -param "<parameter 1>=<value>, ...."] 
	 6) Compile the .sl file 
		[dc_shell> read_lib and write_lib ].
		Use report_lib to check if DC interprets the sl file correctly.
		The read_lib is used to perform only syntax checks of the source.
		report_lib can be used to perform some semantic checks of 
                binding information, pin widths, pin names etc.
		The real interpretation is performed when a compile is performed
		on a design that incorporates the .sldb and the DW part created.
	 7) Verify the components interaction with HLO
                [ all the following steps need to be done in dc ]
	 	Place the .sldb into the synthetic_library variable in dc.
		Create a design that infers an adder, place and vary timing 
		constraints and monitor implementations selected.
		Perform implementation selection and timing checks under varying
		operating conditions and wire-loads.
		

        The numbers signify the sequence of operations. Operations with the same
number signify that these steps can take place in parallel.

KEY POINTS	:

		Summary :
		Creation of a VHDL wrapper that generates the netlist.
		Association of VHDL wrapper with operator via sl file.
		Testbenches and configurations necessary are supplied.
		Link between source HDL and Synthetic Operator not in this 
		example. Please see the std_logic_arith.vhd package in
		$SYNOPSYS/packages/IEEE/src for examples.

		Why is VHDL used in this example? :
		1) VHDL is used because it can handle conditional 
		component instantiation while verilog cannot.
		An example of this is the VHDL generate statement which
		allows users to place a component in a loop and 
		generate multiple instantiations from one statement.
		2) Functions that are defined in verilog also cannot have the 
		parameter value left underfined as you can in VHDL.
		In verilog you cannot define a parameterizable function
		and call it in a module with multiple parameters.
		If you wanted to do this you would have to define
		multiple functions with different names and each
		function would only differ in the defintion of the
		parameter.

		The simulation verification can be performed also by 
		synthesizing the design, writing out the netlist in a 
		convinient format and simulating it at the gate level.

Following is the list of files necessary to implement this design.
	
FILES	: xx_add.vhd		: This is the entity declaration for the ASIC
				  Vendor XX's adder. [File Present]
          xx_add_rpl.vhd	: This is the implementation of the adder where
				  these complex cells will be used to implement
				  a parameterizable adder. [File Present]
	  xx.sl			: This is the synthetic library file definition 
				  to associate xx_add and xx_add_rpl to the "+"
				  HDL Operator.  [File Present]
	  xx.sldb		: This is the compiled file for the .sl source.
          xx_add_tb.vhd		: Parameterized testbench that can be used to
				  verify the component created. [File Present]
	  cfg_tb.vhd		: Configuration that can be used for binding the
				  testbench to the adder to be tested. This 
				  assumes that the .sim files for the leaf 
				  cells (XX4FA and XXFA) have been analyzed 
				  into work.
 				  [File Present]
	  xx.lib		: This is the source file for xx.db library.
				  [File Present]
          xx.db (not here)      : This is the target_library that contains the
				  timing models for XX4FA and XXFA.
				  
	 XX4FA.vhd		: Simulation model of 4 bit adder. 
				  [File Not Present]

	 XXFA.vhd		: Simulation model of 1 bit Full adder.
				  [File Not Present]

	 ASIC vendors should also create simulation models for the leaf cells
	 XX4FA and XXFA. These will be used to simulate the elaborated design
         over a range of parameters.

DC : Design Compiler
VSS: VHDL System Simulator
HDL: Hardware Description Language [Verilog or VHDL]	
